记一次 Git 管理经历

随着负责的项目越来越大，出现了专人维护一个模块的可能，业务与模块划分变得清晰可见，但出现了如下几个问题：

• Source 变的很重
• 模块版本管理变得不灵活
• 开发人员被迫接受很多不要关注的代码

以上问题，促使我寻找一种方案解决这个问题。先简单介绍一下我们的项目构成，由 DMP、DCP、DOP 三个主要业务模块构成，DCP 与其他两个模块之间不存在任何直接关系，DOP 依赖了 DMP 提供的相应基础服务包，DMP 也相对独立，三个模块存在各自发版计划，基于现状，会采用统一的版本号进行管理，这显然是不科学的，所以我提出了使用 GIt Submodule 来解决这个问题。

|-docs
|-apps
|--dop
|--ext
|--toolkit
|-sources
|--basics
|--components
|--templates
|--plugins
|--terminals
|-examples

DMP、DCP、DOP 三个业务模块分别创建一个 Git 进行维护。同时，例如：Basic、Env 、Template 等公共模块都作为子模块进行管理。

DMP

|-docs
|-apps
|--dop(与DOP共用子模块)
|--ext
|--toolkit
|-sources
|--basics(与DOP共用子模块)
|--components
|--templates(与DOP共用子模块)
|--terminals
|-examples(子模块，权限等级可以比较低，以供他人学习查看)

DCP

|-docs
|--toolkit
|-sources
|--components
|--plugins
|--terminals

DOP

|-docs
|-apps(与DOP共用子模块)
|-sources
|--basics(与DMP共用子模块)
|--components
|--templates(与DMP共用子模块)
|--terminals

看似好像模块变多了，但各个业务变得清晰，版本可控，公共部分进行 Git Submodule ，使开发者只要关注需要关注的就行了，模块之间的权限也变的灵活。

Git Submodule 使用

基于已有项目进行改造

• 首先设计需要被 Submodule 的模块，并相应的 Git Repository 创建。
• 将各个子模块的最新数据进行 git push 到相应的远程仓库中，这样子模块的代码已经被管理起来了
• 执行 git submodule add ，需要将相应的子模块目录删除才能执行

拓展

初始化 submodule 项目

git clone --recursive [远程仓库地址]

或者

git clone [远程父仓库地址]
git submodule update --init --recursive
git submodule foreach 'git checkout master; git pull'

变更 submodule 项目路径

Update .gitmodules
git mv oldpath newpath
git rm oldpath
git add newpath
git submodule sync

如何优雅的修改项目版本号

参照

submodule 其他命令参照

参照